In the field of data communications, the success of the Internet has resulted in many businesses, academic institutions and research institutes relying upon the transfer of large volumes of data on a daily basis to support software applications used. However, such organizations are encountering increasing difficulty obtaining communications bandwidths required, and so various Internet research groups are trying to derive measurements that can be used to compare suitability of a path through a communications network with other paths through the communications network for various software applications on a hop-by-hop, transport service provider-by-transport service provider, or Internet Service Provider (ISP)-by-ISP basis. Indeed, there are many applications that can require bulk data throughput, for example: a File Transport Protocol (FTP), or a HyperText Transport Protocol (HTTP), when used to download large images, videos, music and/or large documents, or even large compressed archive files.
One known metric for assisting in the above-mentioned comparison is a so-called Bulk Transfer Capacity (BTC) measurement introduced and described in Request For Comments (RFC) 3148 (www.faqs.org). The BTC measurement provides a network operator or network administrator with an ability to determine whether the communications network is able to support and transfer significant volumes of data over a single congestion-aware transport connection. The BTC measurement can be used to study sustainable transfer capacity along a communications path for bulk data transfers, based upon an expectation that during a course of a communications session, a single congestion-aware transport path reaches equilibrium, i.e. flow control steady state, with the communications network.
An example of a tool for making BTC measurements is known as “TReno” and is described in “Diagnosing Internet Congestion with Transport Layer Performance Tool” (M. Mathis, Proceedings of INET'96, June 1996). TReno (Traceroute RENO) is designed to test network performance under load conditions and employs a congestion control mechanism similar to that of Transmission Control Protocol (TCP), currently the most commonly used Transport Protocol in the Internet.
TReno uses the same technique as a well-known “traceroute” application to probe the communications network, the technique being reliance upon a standard implementation of the widely-deployed Internet Control Message Protocol (ICMP) protocol (as defined in RFC 792). By sending out User Datagram Protocol (UDP) packets with a sufficiently low Time-To-Live (TTL) field, hosts and routers along the path to a final destination send ICMP Time Exceeded messages back that have similar characteristics to (TCP) Acknowledgement (ACK) packets. In particular, such ICMP error messages can be solicited by setting the TTL count to expire just before the UDP packet reaches the final destination. Using this feedback mechanism, TReno is able to send packets at a controlled rate and thus emulate a congestion-aware transport mechanism and perform a BTC measurement. TReno also has a purely ICMP mode, which uses ICMP ECHO Requests instead of low TTL UDP packets.
The TReno tool has been implemented on an IPv4 network with limited success, because it relies upon ICMP messages for determining the BTC measurement. It is known that routers often assign very low priority to the generation of ICMP ECHO requests and ICMP Time Exceeded messages. Furthermore, when experiencing congestion, the routers are especially unlikely to generate these messages with the timeliness and reliability required to assure accuracy in the derived BTC measurements.
Also, since the ICMP protocol conveys potentially multiple so-called “opaque objects” that need interpretation at a target or recipient, it is not uncommon for these messages to be processed in, what is typically referred to as, a “slow path” within routers. Thus, such ICMP messages receive less favourable treatment than traffic that the measurement tool is trying to emulate and measure. Further, some known operating systems also limit a rate at which ICMP messages are used to handle errors or solicit information from neighbouring nodes, for example routers and/or switches. Since the ICMP messages constitute low priority traffic, actions are typically taken by nodes to limit the costs of handling such messages and to avoid congesting the network with such additional traffic.
Additionally, at least in relation to IPv6, RFC 2463 requires IPv6 nodes to specifically limit the rate of ICMPv6 error messages sent by IPv6 nodes in order to limit the bandwidth and forwarding costs incurred in sending the ICMPv6 error messages. Therefore, neither ICMP nor ICMPv6 messages can be relied upon in order to make accurate BTC measurements.
Transit providers, however, need to obtain a BTC measurement and other measurements that are not prone to the limitations or inefficiencies of the mechanisms mentioned above. Additionally, the measurement techniques must still make such measurements statelessly, i.e. make no assumptions about the existence of state, for example in the form of a congestion-aware mechanism that can assist in making such a measurement, at a target end-point or end-points along the path being tested. However, many known tools rely on state being deployed, i.e. additional functionality, along the path being tested or at the end-point or end-points to facilitate the BTC or other similar measurements.
One other known stateful measurement technique, known as “Cap” is described in “Measuring End-to-End Bulk Transfer Capacity” (M. Allman, ACM SIGCOM Internet Measurement Workshop 2001, San Francisco, USA, November 1-2). Like TReno, Cap is a tool that operates in relation to congestion-aware transports. Although other research groups are creating similar tools, these tools are based upon extensions, uses, adaptations or imitations of the TReno or Cap tools.
Both Cap and TReno emulate a type of “idealized” TCP using UDP packets. It is to be noted that there are many variations of TCP being used in current communications networks, because different hosts have different operating systems that implement the TCP protocol in slightly different albeit largely compatible ways, as described in various RFCs. Additionally, routers in communications networks typically do not support the TCP at all; the TCP operates in relation to connections between hosts and so for one or more routers involved in a measurement to support the TCP requires functionality of the one or more routers to be augmented, i.e. the router has to be provided with state in relation to the TCP. This is undesirable, or even not permitted in some communications networks. Further, in relation to Cap, two collaborating end-points are also required, one to act as a source and the other to act as a sink at opposite ends of the communications path under test. Consequently, Cap is also classified as a stateful measurement tool that is congestion-aware. As mentioned above, it is desirable to avoid the provision of state in network nodes to support measurements.